Issue: No linked issue — PR is a performance optimization
PR: #33459 - [UIKit] Avoid useless measure invalidation propagation cycles
Platforms Affected: iOS / MacCatalyst only (src/Core/src/Platform/iOS/MauiView.cs)
Files Changed: 1 implementation, 0 tests
Milestone: .NET 10 SR7
Author: albyrock87 (community contributor)

Key Findings

• PR adds a _measureInvalidatedPropagated bool field to MauiView to act as a per-view deduplication guard, preventing redundant measure invalidation propagation cycles within a single UIKit main run-loop iteration.
• The guard is reset at the start of both SizeThatFits and LayoutSubviews, allowing fresh propagation on each new layout pass.
• The guard applies to both isPropagating=false (origin view) and isPropagating=true (ancestor relay) when HasFixedConstraints=false. This is the intended behavior — once a view has already notified its ancestors to re-layout, additional notifications are redundant because UIKit already has the view in its pending layout set via SetNeedsLayout().
• Motivation: property cascades (e.g., binding context change updating many Labels) each trigger InvalidateMeasure → InvalidateAncestorsMeasures → expensive tree walk per property. This optimization mirrors Android's requestLayout deduplication.
• Previously there was a concern about a failing iOS CollectionView2 test; author confirmed it was resolved after rebasing to main (Apr 9, 2026).
• PR currently has merge conflicts (rebased Apr 9 per author comment).
• CI (ui-tests + device-tests) was re-triggered by kubaflo just before this review.
• No tests added — Gate was SKIPPED for this reason.

Code Concern

• The stale comment // If we're not propagating, then this view is the one triggering the invalidation immediately above the new guard is misleading — the guard now applies to both propagating and non-propagating cases. Comment should be updated to reflect this.
• WrapperView.InvalidateMeasure always returns true (no dedup guard added). However this is not a bug — when the parent MauiView returns false from the dedup check, the ancestor walk in InvalidateAncestorsMeasures stops before reaching WrapperView, so the optimization remains effective.

Fix Candidates

Fix Candidates

Cross-Pollination

Exhausted: Yes

Selected Fix: PR #33459 approach — _measureInvalidatedPropagated bool flag in MauiView

Reason:

1. Simplest implementation (17 additions, 1 file)
2. Most consistent with existing codebase style (follows pattern of other cached bool fields like _parentHandlesSafeArea)
3. Guards BOTH paths (originator + ancestor relay) providing complete deduplication
4. Clear, explicit lifecycle: reset at entry to SizeThatFits and LayoutSubviews
5. Attempt 1 (ancestor-only guard) is a subset of the PR's behavior; PR's approach is more comprehensive
6. Attempt 2 (ThreadStatic HashSet) is functionally correct but introduces shared mutable state, GCD dependencies, and more complexity than needed
7. Attempt 3 (NaN reuse) is clever but fragile — depends on InvalidateConstraintsCache semantics, harder to reason about

⚠️ Final Recommendation: REQUEST CHANGES

Phase Status

Summary

PR #33459 adds a sensible and correct iOS-specific performance optimization to MauiView that prevents redundant measure invalidation propagation cycles. The approach is sound and passes all Layout device tests in independent exploration. However, the PR has two issues that should be addressed before merge:

1. No tests — Gate was skipped because no tests were included. This is a performance optimization, but at minimum a regression test or device test verifying that layouts with multiple rapidly-changing children still render correctly would increase confidence.

2. Stale comment — The comment // If we're not propagating, then this view is the one triggering the invalidation is now misleading because the new _measureInvalidatedPropagated guard applies to BOTH isPropagating=true and isPropagating=false (when HasFixedConstraints=false). The comment should be updated to reflect that the guard prevents redundant propagation in all cases.

3. Merge conflicts — PR currently has merge conflicts (author rebased on Apr 9, 2026; CI re-triggered same day).

Root Cause

In iOS UIKit, MauiView.InvalidateMeasure() → ViewExtensions.InvalidateAncestorsMeasures() walks the entire ancestor view chain via a while loop calling InvalidateMeasure(isPropagating: true) on each ancestor. When multiple properties change in a binding context update (e.g., N Labels in a StackLayout all update their Text), this walk is triggered N times, redundantly calling SetNeedsLayout() on the same ancestor views and walking up the chain N times. After the first walk, UIKit already has all ancestors in its pending-layout set; subsequent walks are pure overhead.

This is the same deduplication that Android's requestLayout() provides natively — once a view has the "needs layout" flag, calling requestLayout() again is a no-op for propagation.

Fix Quality

The PR's fix is correct and is the best among all alternatives explored:

Selected Fix: PR — The PR's implementation is the simplest, most readable, and most consistent with the codebase's existing patterns for cached boolean state.

Issues to address before merge:

• Fix the stale comment above the new guard (it says "If we're not propagating" but the guard applies to both cases)
• Add at minimum a basic layout device test to ensure no regression (e.g., verifying a StackLayout with multiple text-updating Labels renders correctly)
• Resolve merge conflicts